A network is typically used for data transport among devices at network nodes distributed over the network. Some networks are considered “local area networks” (LANs), others are considered “wide area networks” (WANs), although not all networks are so categorized and others might have both LAN and WAN characteristics. Often, a LAN comprises nodes that are all controlled by a single organization and connected over dedicated, relatively reliable and physically short connections. An example might be a network in an office building for one company or division. By contrast, often a WAN comprises nodes that might include nodes over which many different organization's data flow, and might involve physically long connections. In one example, a LAN might be coupled to a global internetwork of networks referred to as the “Internet” such that traffic from one node on the LAN passes through the Internet to a remote LAN and then to a node on that remote LAN.
Data transport is often organized into “transactions”, wherein a device at one network node initiates a request for data from another device at another network node and the first device receives the data in a response from the other device. By convention, the initiator of a transaction is referred to herein as the “client” and the responder to the request from the client is referred to herein as the “server”.
Notably, in some instances, what is normally thought of as the client is in fact the server, as with the example of a window system referred to as “X”. In some instances, a device, program, or other computing entity can be a client for some transactions and a server for others. For example, suppose device A and device B are coupled by a network and device A makes a request for data of device B. For that transaction, device A is the client and device B is the server. Now, if device B only responds to authorized requests, device B might make a request of device A for authentication data. Thus, for the authentication transaction, device B would be the client and device A would be the server, the reverse of the roles for the data request transaction.
As explained above, a transaction over a network involves bidirectional communication between two computing entities, where one entity is the client and initiates a transaction by opening a network channel to another entity (the server). Typically, the client sends a request or set of requests via a set of networking protocols over that network channel, and the request or requests are processed by the server, returning responses. Many protocols are connection-based, whereby the two cooperating entities (sometimes known as “hosts”) negotiate a communication session to begin the information exchange. In setting up a communication session, the client and the server might each maintain state information for the session, which may include information about the capabilities of each other. At some level, the session forms what is logically (or physically, in some cases) considered a “connection” between the client and server. Once the connection is established, communication between the client and server can proceed using state from the session establishment and other information and send messages between the client and the server, wherein a message is a data set comprising a plurality of bits in a sequence, possibly packaged as one or more packets according to an underlying network protocol. Typically, once the client and the server agree that the session is over, each side disposes of the state information for that transaction, other than possibly saving log information.
To realize a networking transaction, computing hosts make use of a set of networking protocols for exchanging information between the two computing hosts. Many networking protocols have been designed and deployed, with varying characteristics and capabilities. The Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP) are three examples of protocols that are in common use today. Various other networking protocols might also be used.
Since protocols evolve over time, a common design goal is to allow for future modifications and enhancements of the protocol to be deployed in some entities, while still allowing those entities to interoperate with hosts that are not enabled to handle the new modifications. One simple approach to accomplishing interoperability is a protocol version negotiation. In an example of a protocol version negotiation, one entity informs the other entity of the capabilities that the first entity embodies. The other entity can respond with the capabilities that the other entity embodies. Through this negotiation, each side can be made aware of the capabilities of the other, and the channel communication can proceed with this shared knowledge. To be effective, this method must ensure that if one entity advertises a capability that the other entity does not understand, the second entity should still be able to handle the connection. This method is used in both the IP and TCP protocols—each provides a mechanism by which a variable length set of options can be conveyed in a message. The specification for each protocol dictates that if one entity does not have support for a given option, it should ignore that option when processing the message. Other protocols may have a similar features that allow for messages to contain data that is understood by some receivers of the data but possibly not understood by other receivers of the data, wherein a receiver that does not understand the data will not fail in its task and will typically forward on the not understood data such that another entity in the path will receive that data.
A message from a client to a server or vice-versa traverses one or more network “paths” connecting the client and server. A basic path would be a physical cable connecting the two hosts. More typically, a path involves a number of physical communication links and a number of intermediate devices (e.g., routers) that are able to transmit a packet along a correct path to the server, and transmit the response packets from the server back to the client. These intermediate devices typically do not modify the contents of a data packet; they simply pass the packet on in a correct direction. However, it is possible that a device that is in the network path between a client and a server could modify a data packet along the way. To avoid violating the semantics of the networking protocols, any such modifications should not alter how the packet is eventually processed by the destination host.
While routing protocols generally control how packets are forwarded through a network, sometimes it is desirable to control the forwarding of an individual packet according to rules that override the normal packet routing logic. A common mechanism for accomplishing this is via a set of packet filtering rules. These rules specify characteristics of individual packets and a desired action or actions to take on each individual packet that meets the characteristics. For example, a firewall employs certain packet filters to dictate that some packets should be forwarded, while other packets should be rejected.
Another mechanism that affects the forwarding of an individual packet and overrides the normal packet routing logic is network address translation (NAT). Using NAT, an entity that receives packets modifies the packet's destination and/or source address before passing on the packet. NAT is commonly used at the border between one network of hosts and another network of hosts (or the Internet as a whole). A router or other such device deployed at the border is configured with a set of rules indicating which packets should have the NAT operation applied, though this may in practice end up being all packets that traverse the device. In this scenario, a set of hosts can be configured with a private range of IP addresses that is not exposed to other hosts in the network—rather the border router rewrites the source address of outgoing packets from the original host's private address to one of a given set of public addresses. This way, the destination server does not need to have routing information to reach the private address, since it perceives all connections as coming from the public address. The router maintains state such that for response packets coming back from the server (addressed to the public destination address), it rewrites the destination and forwards the packet to the original private address, thus routing the packet back to the original client host.
NAT is also used by Layer 4 switch devices (“L4 switches”). An L4 switch is a device that is deployed in the network path that can route all the packets for a particular connection to a destination that differs from the original destination field of each packet in the connection. A common deployment of L4 switches is for use in load balancing. In this type of deployment, a set of servers (each having distinct addresses) is deployed to share the load from client requests such that a connection from a client to a particular server (often called a virtual server) can be routed to and terminated by any server in the set. Rather than rely on the client to choose one of the given servers, an L4 switch is deployed in the network path between the clients and this set of servers. The switch examines the packets and, based on its configuration, uses NAT to forward all packets from a particular client-server connection to a particular server in the set, and conversely, forward all packets from that particular server to the client such that, to the client, the packets appear to come from the virtual server.
Another related concept is that of a network proxy. A network proxy is a transport-level or application-level entity that functions as a performance-enhancing intermediary between the client and the server. In this case, a proxy is the terminus for the client connection and initiates another connection to the server on behalf of the client. Alternatively, the proxy connects to one or more other proxies that in turn connect to the server. Each proxy may forward, modify, or otherwise transform the transactions as they flow from the client to the server and vice versa. Examples of proxies include (1) Web proxies that enhance performance through caching or enhance security by controlling access to servers, (2) mail relays that forward mail from a client to another mail server, (3) DNS relays that cache DNS name resolutions, and so forth.
One problem that must be overcome when deploying proxies is that of directing client requests to the proxy instead of to the destination server. One mechanism for accomplishing this is to configure each client host or process with the network address information of the proxy. This requires that the client application have an explicit proxy capability, whereby the client can be configured to direct requests to the proxy instead of to the server. In addition, this type of deployment requires that all clients must be explicitly configured and that can be an administrative burden on a network administrator.
One way around the problems of explicit proxy configuration is to deploy a transparent proxy. The presence of the transparent proxy is not made explicitly known to the client process, so all client requests proceed along the network path towards the server as they would have if there were no transparent proxy. This might be done by placing the transparent proxy host in the network path between the client and the server. An L4 switch is then employed so the proxy host can intercept client connections and handle the requests via the proxy. For example, the L4 switch could be configured so that all Web connections (i.e., TCP connections on port 80) are routed to a local proxy process. The local proxy process can then perform operations on behalf of the server. For example, the local proxy process could respond to the request using information from its local cache. When intercepting the connection, the L4 switch performs NAT so the connection appears to the client as having been terminated at the origin server, even though the client communicates directly with the proxy. In this manner, the benefits of a proxy can be realized without the need for explicit client configuration.
Some benefits of a transparent proxy require that a proxy pair exist in the network path. For example, if a proxy is used to transform data in some way, a second proxy preferably untransforms the data. For example, where traffic between a client and a server is to be compressed or encrypted for transport over a portion of the network path between the client and the server, a proxy on one side of that portion would compress or encrypt data before it flows over that portion and a proxy on the other side of that portion would uncompress or decrypt the data and send it along the network path, thereby providing for transparent transformation of data flowing between the client and the server.
For actions that require a proxy pair, preferably both proxies in the proxy pair do not perform a transformation unless they can be assured of the existence and operation of the other proxy in the proxy pair. Where each proxy must be explicitly configured with indications of the pairs to which it belongs and to the identity of the other members of those pairs, the administrative burden on a network administrator might well make some operations infeasible if they require proxy pairs. Even where a proxy is interposed in a network and gets all of the traffic from a client or server, it still must discover the other member for each proxy pair the proxy needs, if the proxy is to perform actions that require proxy pairs.